1994-1996 by Oberon microsystems, Inc., Switzerland.
All rights reserved. No part of this publication may be reproduced in any form or by any means, without prior written permission by Oberon microsystems. The only exception is the free electronic distribution of the education version of Oberon/F (see the accompanying
copyright
notice
for details).
Oberon/F module interfaces and their descriptions in particular may not be used in other works without written permission.
Oberon microsystems, Inc.
Technoparkstrasse 1
CH-8005 Z
Switzerland
Oberon is a trademark of ETH Z
rich, Switzerland.
Oberon/F, Oberon/L, "Oberon by Example", "The Oberon Tribune", "Oberon Developer Forum", and "Drag & Pick" are trademarks of Oberon microsystems, Inc.
All other trademarks and registered trademarks belong to their respective owners.
Helvetica
Helvetica
StdLinks.ShowTarget('What')
Helvetica
StdLinks.ShowTarget('Learning')
StdLinks.ShowTarget('Bridging')
StdLinks.ShowTarget('Architecture')
StdLinks.ShowTarget('From')
StdLinks.ShowTarget('Oberon')
Helvetica
Helvetica
StdLinks.TargetDesc
Helvetica
Helvetica
Learning
Bridging
Architecture
HostPictures.StdViewDesc
Geneva
Controllers
Dialog
Views
Models
Stores
Files
Fonts
Ports
Domains
Properties
Containers
Controls
Oberon
Oberon/F
The Oberon Advantage
Copyright Notice
Contents
What's
Unique
About
Oberon/F?
Learning
Past,
Looking
Future
Bridging
Architecture
Explicit
Object-Oriented
Component-Oriented
Programming
Oberon/F:
Holistic
Environment
The main advantage of Oberon lies in its design. In engineering, design is the art of reconciling different, and often conflicting, goals into one elegant and relevant whole. In this chapter, several important aspects of the design that underlies Oberon are highlighted.
What's Unique About Oberon/F?
In short, Oberon/F is the first, and so far the only, cross-platform component framework.
Cross-platform means that it runs on several different operating systems, user interfaces, compound document architectures, and object models. On each platform, it adopts the native look-and-feel, yet source code and documents are completely portable. In this way, Oberon/F becomes a universal integration platform, where Oberon views, OLE objects, and OpenDoc parts can be integrated into powerful applications.
A component framework is an independently extensible and typesafe black-box framework. Let's see what this means:
A framework is a class library which predefines the structure of a certain category of applications. It simplifies the development of new applications in this category.
A black-box framework is based on composition rather than inheritance. Composition allows to achieve a higher degree of independent extensibility, because it relies on a looser and more explicit coupling among objects.
Independent extensibility is necessary if independently developed framework extensions should be able to work together, e.g. as embedded objects in the same document. Independent extensions can be integrated by the end user, at run-time. This is in stark contrast to traditional frameworks and libraries, which can be integrated only by programmers, at link-time.
In a system that consists of many tightly coupled components, reliability of the whole is limited by the least reliable component. The chain is only as strong as its weakest link. Type safety means that an error in one component may only cause limited local damage. Type safety thus guarantees a minimal degree of reliability, which increases the confidence in the system as a whole.
A component framework addresses the issues of resource sharing, e.g. the sharing of screen estate, files, computation time, input devices, name spaces, etc. Interoperating components must be good neighbours; it is the component framework's obligation to define and support rules for cooperative behavior. In an environment where new components may be loaded and integrated at any moment, this requires a carefully designed component framework.
Learning from the Past, Looking to the Future
Oberon is a hybrid language in that it doesn't force everything under the umbrella of object-orientation. Instead, it retains and adapts the most successful features of its predecessors, while adding a few important new concepts. Unlike other hybrid languages however, Oberon isn't just an old language with new features tacked on, in a more or less ill-fitting way. Instead, Oberon provides a clean design where everything fits together. The benefit of this approach is considerable: there is no other similarly simple language which has comparable expressive power.
Bridging the Gap
Programming languages can be loosely divided up into static and dynamic languages. Static languages are usually compiled; examples are Pascal, Modula-2, C, and C++. Dynamic languages are usually interpreted; examples are Lisp and Smalltalk.
Oberon bridges this gap, by combining the best qualities of static languages (readability, maintainability, efficiency, support for programming in the large, support for team programming) with the best qualities of dynamic languages (simplicity, extensibility, safety, support for rapid development, incremental compilation, incremental loading).
As a result, Oberon is powerful enough that whole operating systems can be written in it, yet also simple enough that it can be used for simple automation tasks as well (sometimes this is called writing "macros", "scripts", or "commands"). This solves one of the big problems of today's languages: they either don't scale up to large problems, or they don't scale down to simple problems. In both cases, the results are the same: many projects take longer and become more expensive than would be necessary.
Architecture made Explicit
Many people think that progress in language design is not relevant anymore, because coding makes up only a small part of a project. However, there is an important counter argument:
Programming in the large involves much more than mere coding. More important is the development of an application's architecture, i.e. the way it is composed out of smaller and more manageable pieces, and the interfaces between these pieces. Interfaces can be compared to contracts, since an interface, like a contract, specifies obligations: the obligations of the interface's implementation, as well as the obligations of the interface's clients.
Who would rely on a verbal contract for anything important? A written contract, which specifies each party's obligations as clearly and explicitly as possible, is a much better choice if implementors and clients are different parties, as is usually the case in a component software world (see below).
Yet this is where today's most popular programming languages (e.g. C++, Smalltalk) fall short, because their type systems and module systems are not expressive enough, if they exist at all. These languages cannot explicitly express architectural decisions in an interface. Instead, one must rely on mere conventions or external, ever inconsistent documentation. Oberon on the other hand, with its mature type and module systems, allows to state many architecture decisions clearly and explicitly.
For example, the static structure of a software system can be described by its module hierarchy as the primary system structure, and its type hierarchies as the secondary system structure. A sketch of the Oberon/F module hierarchy is given in the picture below:
Module Hierarchy of Oberon/F
From Object-Oriented to Component-Oriented Programming
In every mature engineering discipline, such as mechanical engineering, systems are built out of components. It's a long time ago that every screw in a car was custom-taylored! Today, a car designer can choose most components of a car from several vendors' catalogues instead.
When looking at commercially available software, it is easy to see that software engineering is still far from mature in this sense. Applications (and operating systems) are huge, complex, and monolithic; instead of small, simple, and composable. What's needed is component software, in order to create a true market for software components. In a component software world, a customer could buy individual components, and integrate them at his or her own site. System integration thus needs to move from the developer's site to the customer's site.
For that to happen, the packaging problem must be solved: objects in the sense of object-oriented programming are too fine-grained to be distributed individually. An object rarely comes alone. Thus it is necessary to bundle several cooperating objects and their types together into one component. Traditional OOP is not concerned with component software; and as a result, packaging issues have not been addressed in traditional OOP languages such as C++, Smalltalk, or Eiffel.
Here Oberon's module system comes in. Modules and type safety lift object-oriented programming to component-oriented programming, paving the way for a mature component software market.
This allows a shorter definition of the term component framework: a component framework is a component-oriented framework.
Oberon/F: a Holistic Environment
In Oberon/F, software is written, executed, debugged, and documented within one and the same integrated development environment (IDE). Due to this integration and the very fast incremental compiler, quick "turn-around" times can be achieved, i.e. it takes very little time to modify the behavior of a program under development. Unlike most other tools with this property, there is no run-time penalty to pay when working with Oberon: the compiler generates efficient 32-bit native code. This makes it possible to use Oberon programs not only for prototyping purposes, but also for actual use (rapid development instead of rapid prototyping only). Oberon/F itself is proof of this: it is entirely written in Oberon, including the Oberon compiler itself!
This has an interesting and important consequence: Oberon/F, just like any other Oberon program, consists of a collection of modules. Except for a minimal set of pre-linked core modules, these modules are treated exactly the same way as any application modules, there is no artifical "magic" boundary between Oberon/F and software developed in Oberon/F. This means that new components (single modules or whole subsystems, i.e. collections of modules) can be added to Oberon/F, on equal footing with the standard text, form, and development subsystems. In particular, newly written and compiled modules can be loaded immediately and without explicit linking step, effectively extending Oberon/F at run-time.
Oberon/F is completely integrated, yet it is not an island! OLE and OpenDoc support allows to integrate non-Oberon components into Oberon/F. On the other hand, Oberon/F components can also be packaged as OLE or OpenDoc components. Oberon/F is a cross-platform integration technology for components, independent of the particular underlying standards.
(.txt)